Nel luglio 2024, il più grande blackout IT della storia non fu causato da un attacco hacker. Fu causato da un aggiornamento difettoso del software di sicurezza più diffuso al mondo. L’ironia è perfetta — e racconta qualcosa di strutturale sul modo in cui concepiamo la resilienza.

CrowdStrike — azienda di cybersecurity con circa il 18% del mercato globale della protezione endpoint — distribuì un aggiornamento difettoso al proprio software Falcon Sensor per Windows. In meno di un’ora, 8,5 milioni di sistemi andarono in crash simultaneo, mostrando il famoso “schermo blu della morte”. Compagnie aeree, ospedali, banche, mercati borsistici, servizi di emergenza: tutto si fermò. Le perdite dirette stimate, secondo Fortune, per le sole aziende Fortune 500 ammontarono a 5,4 miliardi di dollari.

La causa non fu un attacco esterno. Fu un errore in un file di configurazione da pochi kilobyte — il Channel File 291 — che conteneva un’incongruenza tra il numero di campi definiti nel template (21) e quelli effettivamente forniti dal sensore (20). Un bug banale, in un meccanismo di aggiornamento automatico e silenzioso, diffuso simultaneamente a scala globale senza possibilità di rollback immediato.

Il paradosso è geometricamente preciso: il software installato per difendere i sistemi era diventato il loro punto di failure più critico. Southwest Airlines, l’unica major aerea completamente immune all’outage, si salvò non grazie alla sua modernità infrastrutturale, ma nonostante l’assenza di essa — i suoi sistemi, notoriamente obsoleti, non eseguivano CrowdStrike Falcon.

Per decenni, il paradigma dominante della sicurezza informatica è stato additivo: più controlli, più protezioni, più strati. Firewall sopra firewall, sistemi SIEM per aggregare log, EDR per monitorare endpoint, SOAR per orchestrare risposte, CASB per il cloud, PAM per gli accessi privilegiati. La cybersecurity stack media di un’organizzazione enterprise conta oggi tra 50 e 80 strumenti distinti, ciascuno con le proprie dipendenze, aggiornamenti, integrazioni e potenziali failure mode.

Il WEF Global Cybersecurity Outlook 2025 documenta questa tensione strutturale con precisione: i provider critici che dominano l’ecosistema diventano essi stessi punti di failure sistemici. Qualsiasi vulnerabilità introdotta attraverso di loro non produce solo effetti sulla propria client base diretta, ma genera un’onda d’urto sull’intero ecosistema interconnesso.

Quasi ogni organizzazione di dimensioni medie o grandi dispone oggi di un piano di Business Continuity (BCP) e di un piano di Disaster Recovery (DRP). Molte sono certificate ISO 22301. Eppure, quando l’incidente reale arriva, la distanza tra il piano e la realtà operativa si rivela spesso abissale.

Il caso Delta Airlines dopo l’outage CrowdStrike è emblematico. Mentre altre compagnie aeree — American, United — ripristinarono le operazioni entro 24-48 ore, Delta impiegò settimane e subì perdite stimate in 500 milioni di dollari. Non perché i suoi sistemi fossero più colpiti, ma perché la risposta manuale richiesta — avviare in modalità sicura milioni di macchine cifrate con BitLocker, inserire chiave per chiave i codici di ripristino a 48 cifre — aveva saturato la capacità operativa umana. Il piano di continuità era scritto per scenari cyber, non per uno scenario in cui il software di sicurezza stesso era il problema.

Accenture, nel suo State of Cybersecurity Resilience 2025, fotografa questa frattura in modo quantitativo: solo il 10% delle organizzazioni rientra nella cosiddetta “Reinvention-Ready Zone” — quella in cui capacità tecnica e strategia cyber sono realmente integrate. Il 63% naviga nella cosiddetta “Exposed Zone”, privo sia di strategia che di capacità tecnica adeguata, risultando un bersaglio privilegiato per le minacce più avanzate.

C’è un secondo paradosso, meno visibile ma ugualmente strutturale: l’automazione della sicurezza produce nel tempo un deskilling sistematico del personale operativo. Quando i sistemi funzionano, l’automazione è efficiente e desiderabile. Ma quando i sistemi falliscono — e falliscono sempre, prima o poi — la capacità di risposta manuale si rivela atrofizzata da anni di non utilizzo.

Il fenomeno è analogo a ciò che l’aviazione chiama “skill fade”: i piloti di linea che volano con autopilota per migliaia di ore perdono progressivamente la capacità di gestire situazioni eccezionali in controllo manuale. Nel dominio della cybersecurity, il parallelo è diretto: i team che hanno delegato monitoring, risposta agli incidenti e patch management a strumenti automatizzati faticano a operare efficacemente quando quegli stessi strumenti si rivelano il problema.

Nel 2012, il matematico e filosofo del rischio Nassim Nicholas Taleb introduceva il concetto di “antifragilità” — la proprietà di sistemi che non solo resistono agli shock, ma ne traggono beneficio, diventando più capaci sotto pressione. La distinzione è precisa: il fragile si rompe sotto tensione, il robusto resiste, l’antifragile migliora. La resilienza classica è robustezza, non antifragilità.

La tesi di Taleb applicata alla cybersecurity moderna produce una diagnosi scomoda: le organizzazioni che accumulano layer di protezione, che eliminano ogni possibile fonte di variazione e incertezza operativa, che ottimizzano ogni processo per la massima efficienza — stanno sistematicamente fragilizzando se stesse. Stanno costruendo sistemi che sembrano sicuri in condizioni normali e che collassano in modo catastrofico quando le condizioni normali cessano di essere tali.

Il meccanismo che Taleb chiama “iatrogenics” — il danno prodotto dall’intervento terapeutico stesso — si applica con precisione chirurgica alla cybersecurity moderna. Ogni nuovo strumento di protezione aggiunto a uno stack già complesso porta con sé: nuove integrazioni da mantenere, nuove superfici di attacco potenziali, nuovo personale da formare, nuovi aggiornamenti automatici da gestire. La cura diventa parte del problema.

Il dibattito regolatorio europeo — NIS2, DORA, Cyber Resilience Act — si muove ancora largamente nell’alveo della resilienza tradizionale: più requisiti, più audit, più certificazioni, più obblighi di notifica. Sono prescrizioni necessarie e in larga parte corrette. Ma raramente affrontano la domanda di fondo: stiamo costruendo sistemi che imparano dai failure, o sistemi che cercano di non fallire mai — e che inevitabilmente crolleranno quando lo faranno?

C’è una dimensione strutturale del paradosso che la discussione tecnica raramente include: la concentrazione del mercato dei vendor di sicurezza è essa stessa un moltiplicatore di rischio sistemico. CrowdStrike, con il 18% del mercato globale della protezione endpoint, è un esempio particolarmente evidente. Microsoft, con la sua presenza trasversale in sistema operativo, cloud, produttività e sicurezza, lo è ancora di più.

La logica di mercato che ha prodotto questa concentrazione è razionale a livello individuale: le organizzazioni standardizzano su pochi vendor per ridurre la complessità di gestione, negoziare economie di scala, semplificare la formazione del personale. Ma ciò che è razionale a livello microeconomico diventa un rischio sistemico a livello macro: ogni singolo vendor dominante trasforma la propria base clienti in un failure domain correlato — quando un componente cede, tutti cedono simultaneamente.

Dal punto di vista dell’analisi del rischio, il problema è che la correlazione tra failure di organizzazioni diverse — attraverso vendor condivisi — non è tipicamente inclusa nei modelli di rischio individuali. Ogni CISO valuta il rischio della propria organizzazione; quasi nessuno valuta il rischio sistemico che emerge dall’interdipendenza tra organizzazioni attraverso la supply chain digitale condivisa.

La resilienza, nel suo senso autentico, è la capacità di un sistema di assorbire perturbazioni, adattarsi, e tornare a una condizione funzionale — possibilmente migliore di quella precedente. Ciò che molte organizzazioni chiamano resilienza oggi è qualcosa di diverso: è l’accumulo di meccanismi progettati per prevenire il failure in condizioni note, che producono fragilità sistemica in condizioni ignote.

L’illusione è strutturata perché ha una sua coerenza interna. I framework esistono, le certificazioni vengono rilasciate, i report di compliance vengono prodotti, i CDA firmano le attestazioni. Il sistema è perfettamente funzionale — finché le condizioni rimangono quelle per cui è stato progettato. Il problema è che le condizioni cambiano, i threat actor evolvono, i vendor dominanti commettono errori, e la realtà produce regolarmente scenari che non erano stati inclusi nei tabletop exercise.

Uscire dall’illusione non richiede di smantellare l’architettura di sicurezza esistente. Richiede di smettere di trattare la resilienza come uno stato da raggiungere attraverso certificazioni e strumenti, e di iniziare a trattarla come una capacità da esercitare continuamente attraverso failure controllati, stress test reali, e una riduzione deliberata della dipendenza da singoli punti di controllo — anche quando quei punti sono i propri strumenti di sicurezza.